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VAXcluster Types 
Lesson Introduction 

This module discusses VAXcluster configurations. The two major types of 
VAXcluster configurations are Heterogeneous and Homogeneous. 

A Heterogeneous VAXcluster is a collection of VAX systems that can share 
resources. "~ 

A Homfigfinfious VAXcluster is a collection of VAX systems that have identical 
operating environments. 

Lesson Objectives 

1. Describe the characteristics of a Homogeneous VAXcluster. 

2. Describe the characteristics of a Heterogeneous VAXcluster. 

3. Define partitioning and describe how to avoid it. 

4. Define Quorum. 

Lesson Outline 

I. VAXcluster Types 
El. Configurations 
IE. Quorum 
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VAXcluster Overview 

The operating environment of a VAXcluster can be three basic types: 

- Homogeneous 

- Heterogeneous 

- A mixture 
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The Homogeneous VAXcluster 



• Homogeneous VAXclusters have the following characteristics: 

- Shared SYSUAF.DAT provides identical accounts on all nodes. 

- Same logical names defined on all nodes. 

- Mass storage devices and queues are shared. 

- Users have the same data access from each processor (node). 

- Users can continue to work despite failure of a node. 

• Example: 

A university time-sharing system used for student and instructor 
programming. Users may login to any node and still access their data on a 
shared HSC50 disk. This configuration provides a highly available computer 
system; if a CPU is removed from service for maintenance, the users can 
switch to another. 
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The Heterogeneous VAXcluster 

• Heterogeneous VAXclusters have these characteristics: 

- Each VAX processor presents a different operating environment to users. 

- Each node is autonomous, although data can be shared between them (not 
totally secure). 

- Can service specialized needs while allowing for sharing of data. 

- Mass storage devices and queues may not be available from every node. 

• Example: 

A corporation's central computer system, where the accounting engineering, 
and manufacturing departments each have their own computer system, can 
access a shared database containing inventory information, product orders, 
and scheduling data. 
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Homogeneous and Heterogeneous Clusters Combined 
• A mixture of environments has these features: 

- Some resources (storage devices) are shared between all nodes while others 
are not. 

- Some nodes have identical environments while others have different 
environments. 

Example: 

A three-node cluster in which two nodes provide a homogeneous time-sharing 
environment and a third node performs batch processing. 
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VAXcluster Configurations 

• All clusters (whether homogeneous or heterogenous) share certain 
characteristics: 

- Each VAX has its own system root; that root could be on a local disk or a 
shared HSC disk. 

- Each node has a hardware node address set in the switches of the LINK 
board of the CI interface. 

- Each node has a software system ID set up under SYSGEN (or under 
SEJSHOforanHSC). 

- Each node has a node name set up under SYSGEN (or under SETSHO for 
an HSC). 

- Each node has a DECnet node number and name (VAX systems only) that 
match the system ID and node name. 

- Names of devices reflect physical access paths. 

- Names of dual- ported devices are based on allocation class numbers. 
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VAXcluster Configurations (Cont.) 

( t ) The cluster shown on the opposite page has the following characteristics: 



- Each VAX has its own system disk. 

- Both VAX systems share a dual- ported RM05. 

- Access to the RM05 is possible because of the CI Bus connecting the two 
nodes. 

Each node has its own node number, node name, and allocation class 




number. 
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VAXcluster Configurations (Cont.) 

• The cluster shown on the opposite page has the following characteristics: 

- Multiple systems are booted from one HSC disk. 

- Two disks are dual-ported between two HSCs. 

- One disk is available to the cluster through the MSCP server, and is dual- 
ported between VAX nodes. 

- All systems can access any disk via the HSC or the MSCP server. 

- Terminals connected to a terminal server located on the ETHERNET allow 
; users to switch between systems in case of a node failure. 
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The Quorum Scheme 

• The Connection Manager on each node of a cluster performs the following: 

- Determines what nodes are in the cluster, 

- Reconfigures the cluster as nodes join or leave it. 

- Provides coordination between nodes to ensure the integrity of shared 
resources. 

• Partitioning exists when nodes of a cluster divide into two or more groups, 
each unaware of the other's existence. This causes disk file corruption since 
there will not be coordination between all systems sharing the same 
resources. 

• The quorum feature prevents partitioning. 

• The quorum scheme: 

- Each VAX node contributes a fixed number of votes toward a quorum. 

- The Connection Manager dynamically computes CLUSTER VOTES as the 
sum of all the votes by all members. 

- Each VAX node specifies an initial quorum value. 

- As nodes join/leave the cluster, the connection manager dynamically 
computes the cluster quorum to be the largest of the following: 

a. The current cluster quorum value. 

b. The value for quorum specified by each node. 

c. The value calculated from the formula: 

(total votes + 2)12 
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The Quorum Scheme (Cont.) 
• Partition Prevention: 



5^ r ccu^T /cf ^/^ 00 ^ u ^~ 



J 1 




- If more than half the nodes form a functioning cluster, then the remaining 
nodes can never become a separate cluster. 

- If the current cluster quorum drops below quorum value, the cluster ^ — ^JJ ^^ 
members suspend all process activity (cluster hangs). iXA 

- Quorum value is never lowered by the Connection Manager; only the 
System Manager can do this undecSffi&jj^j^ \)MS <^ 

The number of votes per node and quorum are determined by SYSGEN 
parameters VOTES and QUORUM. 
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Special Case for Quorum: Two- Node VAXcluster 

• The quorum scheme has a problem in a two-node cluster configuration: 

- The computation of quorum results in (2 + 2)/2 = 2. 

- This means both nodes must be present to function. 

- The solution is to obtain another voting member. 

• The quorum disk solution ~ A quorum disk may act as a virtual node in a 
cluster, adding votes to achieve quorum. 

• Conditions for using a quorum disk: 

- The name of the disk must be specified on all nodes and must be the same 
on all nodes. 

- The disk must be accessible by every node. 

- The disk must contain a valid format file named QUORUM.DAT in the 
Master File Directory. 

• The name of the quorum disk and the number of votes contributed toward 

quorum are specified by SYSGEN parameters DISK QUORUM and 

QDSVOTES. 

• Therefore, a system booting into a cluster has three choices: 

- Join an existing cluster. 

- Form a cluster where no cluster exists. 

- Hang until quorum is reached. 

• Note that computing quorum entails knowing how many members are in the 
cluster and how many votes each member contributes toward quorum. This is 
done by the Connection Manager. 



VAXcluster Types 



1-16 




2 -f * A 
{ f/VO FfiftovB^ 




'J fey /9bbf/c& 

/F (p\s£>Pi(S/y 



VlSK<5 VcTbs TO 

TcTftu Veres OF THE 
SYSTEM 5 

Also &esr r ^ 
vnweb Disk tmr yov vowuh 



st/c Acs 



SYSTEM BOOTING WITH A CI PORT 



System Booting with a CI Port 
Lesson Introduction 

This module discusses the sequence of events while booting a VAX into a cluster and 
how it differs from booting outside of a cluster. 

The boot file CIBOO can be modified and the new file saved as the default boot file. 
Shutting the system down and system time are also discussed. 
Lesson Objectives 

1. List the sequence of events during a system boot. 

2. Describe the changes that must be made to the boot file in order for the system 
to boot from a specific system root on an HSC-based disk. 

3. Shut down one or more nodes in a cluster without hanging the remaining 
systems in the cluster. 

Lesson Outline 

I. Local Disk 

H. HSC Disk 

m. Shutdown 

IV. Time 
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System Booting with a CI Port 



Overview 

• There are two ways to boot VAX within cluster: 

- Boot from an HSC disk 

- Boot from a local disk 

• Both methods are discussed on the following pages. 
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Booting From a Local Disk 

• Before VMS is brought up, a linked chain of files are executed. Each link in 
the chain is described in the following sections. 

• CI Port initialization, when booting from a local disk, follows this sequence: 
VMB.EXE (primary bootstrap) <£}CPl° tffr*^ 

a. Loaded from console media. v NL < (j*>0 , 7^ b L^e^^ ^ 

b. Sizes msEfea and identifies adapters; if CI Port is found, it loads the CI 
microcode (CI780.BIN) from the console device into a nonpaged pool. 

c. Loads SYS^OOT from the system disk using a skeleton driver. 
SYSBOOT 

a. Configures the processor by loading parameters unique to the 
processor. 

b. Divides system virtual address space into sections and defines the 
system page table. 

c. Loads and runs executive image SYS.EXE. 
SYS.EXE 

a. Includes SCS routines and CLUSTRLOA.EXE, which contains the 



V .artC» / b. Transfers control to INIT. 



Connection Manager. 
pX INIT 

I ^ a. Turns on memory management. 

b. Initializes nonpaged pool. 

~ /*o\T$ fi*>M>T£&S roc 

c. Creates adapter control block for CI Port. 

d. Starts the scheduler. 
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Booting From a Local Disk (Cont.) 

The scheduler schedules the swapper process, which then creates the SYSINT 
process. 

SYSINIT.EXE 

Prompts roR- Time 

a. The Connection Manager is initialized and attempts to join cluster. 

b. The system disk is mounted. 

c. Page file, swap file, and dump file are opened. 

d. STARTUP.COM is invoked. 
STARTUP.COM 

a. Start ERRFMT, OPCOM, CLUSTER SERVER, JOB__CONTROL. 

b. SYSGENrun. Cc/of\(jufl£. U*(ib\JArR.& 

c. SYSTARTUP.COM invoked. 
SYSTARTUP.COM is a site-specific startup file. 
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Booting From an HSC Disk 

• Before VMS is brought up, a linked chain of files are executed. Each link in 
the chain is described in the following sections. 

• CI Port initialization, when booting from an HSC disk, follows this sequence: 
VMB.EXE (primary bootstrap) 

a. Loaded from console media. 

b. Sizes v&&fc& and identifies adapters; if the CI Port is found, it loads the 
CI microcode (CI780.BIN) from the console device into physical 
memory. 

c. VMB contains a skeleton CI device driver that is used to load 
SYSBOOT. It loads microcode into the CI Port, establishes a virtu al 
circuit to HSC. establishes a conne ction to the di sk server, and loads 
SYSBOOT from the d isk. r otOuNE Of^ rfSC 

SYSBOOT (secondary bootstrap) 

a. Configures processor by loading parameters unique to the processor. 

b. Loads port driver (PAD RIVER) and disk class driver (DUDRIVER). 

c. Loads and runs executive image SYS.EXE. 
SYS.EXE 

a. Includes SCSLOA.EXE (SCS layer) and CLUSTRLOA.EXE 
(Connection Manager). 

b. Transfers control to INIT. 
INIT 

a. Turns on memory management. 

b. Initializes nonpaged pool. 

c. Creates adapter control block that describes the CI Port. 
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Booting From an HSC Disk (Conk) 

d. Initializes PAD RIVER |CI Port driver) and flUD RIVER (disk class 5r ^ r ^ b^ f 
driver) for use. ^ — — \ t> &f f<5 b ^ Port C te-tfr 

(ST? Lock Manager is initialized. # C ^ /A) 

f. Starts the scheduler. 

The scheduler schedules swapper process, which then creates the SYSINIT 
process. 

SYSINIT .EXE 

a. The Connection Manager is initialized and attempts to join the cluster. 

b. The system disk is mounted. 

c. Page file, swap file, and dump file are opened. 

d. STARTUP.COM is invoked. 
STARTUP.COM 

a. Start ERRFMT, OPCOM, CLUSTER SERVER, JOB_CONTROL. 

bo System logical names are created. 

c. SYSGENisrun. 

d. SYSTARTUP.COM is invoked. 
SYSTARTUP.COM is site-specific startup file. 

a. Starts batch and print queues. 
^ \jY ' b. Creates site-specific logical names. 

c. Mounts volumes other than system disk. 

d. Starts DECnet. 
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Booting From an HSC Disk (Cont.) 



• If you are booting from a remote disk, the processor must be able to find that 
disk in order to load SYSBOOT. 



• The boot files on the console media are used to "point" the CPU to the 
appropriate disk. 

• ThemostimportantfileiscalledCIBOO.CMD. <?><?0 " 

, Cc: M " 

(4< Before running CIBOO.CMD, registers R2 and R3 must be filled with valuj 
NL^ that tell VMB.EXE where to find the system disk: 



; »>0 R2 0304 ;HSC #3 AND #4 (hex) 
Y »>D R3 1 ;disk #1 (hex) 
C-_>»SCIB00.CMD 

w + CIBOO.CMO 



CI PORT BOOT COMMAND FILE - CIBOO.CMO 
BOOT FROM CI 

DESIRED STATION ADORESS OF REMOTE 
PORT IS SET IN REGISTER 2 AND THE 
DESIRED UNIT NUMBER IS SET IN REGISTER 
3 BEFORE EXECUTING THIS COMMAND FILE 




HALT 
UN J AM 
INIT 

DEPOSIT/I 11 20003800 
DEPOSIT RO 20 
DEPOSIT Rl E 
DEPOSIT R4 
DEPOSIT RS 4000 
DEPOSIT FP 
START 20003000 
WAIT DONE 
j 

EXAMINE SP 

L0A0 VMB. EXE/START; 8 
START 9 



HALT PROCESSOR 
UN J AM SB I 
INIT PROCESSOR 
SET UP SCBB 
CI PORT 0EVICE 
CI TR*E 

BOOT BLOCK LBN (UNUSED) 
SOFTWARE BOOT FLAGS 
SET NO MACHINE CHK EXPECT 
START ROM PROGRAM 
WAIT FOR COMPLETION 

SHOW A00R OF WORKING MEM+'X200 
LOAD PRIMARY BOOTSTRAP 
START IT 
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Booting From an HSC Disk (Cont.) 



• CIBOO is normally copied to a disk using EXCHANGE, edited to contain the 
correct values in R2 and R3, and then copied back to the console as 
DEFBOO.CMD. 

• R3 needs to be further modified if volume shadowing is used. 

• R5 is used for software control to: 

Boot conversationally, into the Diagnostic Supervisor, or into VMS: 



Boot into root directory other than 0: 

R5 = 10004000 ; boot from SYS1 
R5 = 50004000 ; boot from SYS5 

• CIBOO.CMD is normally modified under EXCHANGE and renamed 

CIGEN.CMD (conversational boot) or SCIBOO.CMD (Diagnostic Supervisor 
boot). 'tort 



R5 = 00004000 
R5 = 00004001 
R5 = 00004010 



boot to VMS 

conversational boot 

boot into Diagnostic Supervisor 



oppg/i bit /*> 




^ 00 C <DO<D I 
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Sample CIGEN.CMD 
• Example CIGEN.CMD: 



CIGEN.CMD 



M PORT CONVERSATIONAL BOOT 
COMMAND FILE - CIGEN 
BOOT FROM CI 



OESIRED STATION ADORESS OF REMOTE 
PORT IS SET IN REGISTER 2 AND THE 
OESIRED UNIT NUMBER IS SET IN REGISTER 
3 BEFORE EXECUTING THIS COMMAND FILE 



^7 



HALT 
UN J AM 
INIT 

DEPOSIT/I 11 20003800 
DEPOSIT RO 20 

DEPOSIT R^ JE 

DEPOSIT R4 ^ 
DEPOSIT R5 4001 
OEPOSIT FP 
START 20003000 
WAIT DONE 



HALT PROCESSOR 
UN J AM SB I 
INIT PROCESSOR 
SET UP SCBB 
CI PORT OEVICE 
CI TR»E 

BOOT BLOCK LBN (UNUSED) 
SOFTWARE BOOT FLAGS 
SET NO MACHINE CHK EXPECT 
START ROM PROGRAM 
WAIT FOR COMPLETION 



EXAMINE SP 

LOAD VM8.EXE/START;9 
START 8 



! SHOW AOOR OF WORKING MEM+'X200 
! LOAD PRIMARY BOOTSTRAP 
! START IT 
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Sample DEFBOO.CMD 

• The following is an example of booting a VAX- 11/750 from a disk attached to 
anHSC. 

• Note that it is really an edited version of CIBOO.CMD. 



D/G 
D/6 
0/G 
D/G 
0/G 
D/G 
D/G 



CI PORT BOOT COMMAND FILE 
BOOT FROM CI 



CIB00.CM0 



THE DESIRED STATION ADORESS REMOTE 
PORT IS SET IN REGISTER 2 AND THE 
DESIRED UNIT NUMBER IS SET IN REGISTER 
3 BEFORE EXECUTING THIS COMMAND FILE. 



20 

F3E000 
0100 



10000000 
200 



LOAD VMB. EXE/START: 200 



START 200 



CI PORT DEVICE 
CI TR=E 
HSC 1 OR 
DISK UNIT 

BOOT BLOCK LBN (UNUSED) 
SOFTWARE BOOT FLAGS SYS 1 
ABOireSS Of WORKING MEMORY 

LOAD PRIMARY BOOTSTRAP 
START IT 



*200 
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Node Shutdown in a Cluster ^ T vom * 

• Shutting down a system removes votes from the cluster quorum. 

• If the total number of votes drops below the cluster quorum, the remaining 
nodes will hang. 

• During normal shut down of a node (SYS$SYSTEM:SHUTDOWN), the 
shutdown procedure has the following options: 

REMOVE NODE: Removes node and recomputes the quorum value for the 

cluster using the votes available from all the nodes in the cluster including 
the node performing the shutdown. 

D ^ ^ CLUSTER_SHUTDOWN: All nodes will suspend activity and shut down 
jjACfr *^ty ^foS e ther, after this option has been specified on each node. 

• If nodes crash or are removed from the system for an extended period of time, 
it may be necessary to lower the quorum in the remaining nodes: 

$ set cluster/quorum = n (new value for quorum) 

$ set cluster quorum (nodes compute new quorum) 

• The SET TIME command only affects the node on which it is entered (possible 
to have different times on different nodes). 
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Device Naming in a VAXcluster 
Lesson Introduction 

This module discusses naming conventions in a VAXcluster. The name for a device 
in a cluster can be derived from either the node it is directly connected to or the 
Allocation Class of that node, if one is used. 

Lesson Objectives 

1. Describe the use of Allocation Class. 

2. List the steps required to serve a dual-ported disk to the cluster. 

3. Describe the installation and use of volume shadowing. 

4. Explain how to find information concerning mount disk volumes in a 
VAXcluster. 

Lesson Outline 

I. Introduction 

EE. Dual-Pathed Devices 

HI. Local Disks 

IV. Volume Shadowing 

V. Status 
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vice Naming in a VAXcluster 



Disk and Tape Device Names 

• Disk or tape device names are of the form < node > $ < device > , where: 

- Node is the name of the node (HSC or VAX running MSCP server) to which 
the device is connected. ^ sc 

- Device is the physical device name. ^ ^V** / 



• For example, a disk named HSC004$DUA1: is connected to HSC004 and is an 
RA81. 

-+- \ A device that is conncLtcd locally (no t served to Llni " clm > lcr) w4 U-no£~be 
■p reced e d by the aude nam ^ c 1 
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Dual-Pathed Device Names 

• A dual-ported device is accessible through more than one path. 

• Names of devices must reflect physical access paths. 

• The name of a dual-ported device is based on an allocation class assigned to 
each node connected to that device: 

- Allocation class is used to form a single name for a dual-ported device. 

- Allocation class is a number (0 to 255) given to a VAX by SYSGEN 
parameter ALLOCLASS, or SET ALLOCATE DISK on an HSC. 

- The allocation class number must be both non-zero and identical on both 
sides of the dual-ported device. 

• Result is a device name of $ < class > $ < device > , where: 

- Class is a number between 1 and 255. 

- Device is the physical drive. 

• For example, $l$dra3: would be an RM05 drive connected between two nodes 
with allocation class 1. 
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MFAO: 



^HSC003$MUAOO> 



VAXASDRAO 
(S1SDRAO:) 




VAXBSDRA1 : VAX8SORA2: 
($1$DRA1:) (S1SORA2:) 



$255SOUA1:^ A^-^^Ss 
HSC003SDUA1 :) \ 
HSC004S0UA1 :) jJ^i^^T 
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Disk Device Names in a VAXcluster 
with Dual-Ported Disks 
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Local Disks in a Cluster 

• Local disks are not automatically cluster accessible. 

1 1 a • The MSCP server must be called up and then the device "served" to the 
fD^l>^ cluster. 

- The following commands load the MSCP server: 




S RUN SYSSSYSTEM : SYSGEN 
MSCP 
EXIT 



- The following command will make a disk available cluster- wide: 



S SET DEVICE/SERVED LARRYS0RA4: 




• If the disk is going to be dual- ported, this must be specified before the disk is 
mounted by the following DCL command: 

$ SET 0EVICE/DUAL_PORT $2$DRA0: 

- A MASSBUS disk may be used as either a system disk or a dual-ported 
disk, but not both. 

- Note that the above command makes this disk available to all cluster 
nodes, not just the nodes physically connected to the disk. 
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Mounting Disks in a Cluster 

• When mounting a disk, the following guidelines are useful: 
- On the system serving the disk, type: 



S MOUNT/CLUSTER <devi c8-name> 



- On a system not serving the device, type: 



$ MOUNT/SYSTEM <devico-name> 



• Sample commands for the disk configuration given on the following page: 



FOR SYSTEM MOE 



S SET ITOQN. 

S RUN SYSSSYSTEM : SYGEN 
MSCP 

EXIT 

$ SET 0EVICE/DUAtJ»ORTED/SERVEO SlSOKAO 
$ SET OEVICE/SERVED MOESDMAO 
$ MQUMI/Cl 11STFR/NDA.SS1ST MOESOMAQ 
$ MOUNT /(*J ttSTER/NOASSIST $1$DRA0 
$ MniiMT/^vsTpM/Mnft^^T DUDS0UA3 
$ MOUNT/SYSTEM/NOASSIST $255$0UA2 



PROO_OISK 
OOC_DISK 
WRK3 
WRK4 



WRKD1$ 
WRKD2S 
WRKD3S 
WRK04S 



FOR SYSTEM LARRY 
$ SET NOON 

$ RUN SYSSSYSTEM : SYSGEN 
MSCP 
EXIT 

S SET DEVICE/OUAL_PORTED/SERVED S1SORA0 
S MOUNT/CLUSTER/NOASSIST $l$ORA0 
S MOUNT/SYSTEM/NOASSIST 0U0$DUA3 
S MOUNT/SYSTEM/NOASSIST $255$0UA2 



DOC_0ISK 

WRK3 

WRK4 



WRKD2S 
WRK03S 
WRK04S 



FOR SYSTEM CURLEY 
S SET NOON 

$ MOUN T/SYSTEM /NOASSIST DUOSDUA3 WRK3 WRK03S 

$ MOUNT/SYSTEM/NOASSIST STg5SO pA2 WRK4 WRKD4S 
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Mounting Disks in a Command Procedure 



• The command procedure below will automatically mount all the disks shown 
in the preceding illustration. 

• In a command file, always use the qualifier /N O ASSIST with the MOUNT 
command. 

• The qualifier /N OREBUILD should be used if you are not mounting the disk 
for the first time (not done in this procedure). 

$ SET NOON - — ' 

S ! Moe serves his local disks 

S IF FSGETSYI ( "NOOENAME" ) .#|ES. "MOE" THEN GOTO N0T_MOE 
$ RUN SYSSSYSTEM : SYSGEN 

MSCP 

EXIT 

S SET OEVICE/OUAL_PORTED/SERVEO S1S0RA0 
S SET DEVICE/SERVED MOESDMAO 

$ NOT_MOE : <t—~ 

S ! Larry serves his local disks 

S IF F$_GETSYI( "N_Q.QE.NAME" ) v.NES. "LARRY" THEN GOTO NOTJ.ARRY 
$ RUN SYSJSYSTEM: SYSGEN 

MSCP 

EXIT 

S SET 0EVICE/OUAL_PORTE0/SERVEO StSDRAO 
$ NOT_LARRY : ^ _ 

S ! Moe mounts his local disks for the rest of the cluster 
$ IF FSGETSYI ("NOOENAME") .EQS. "MOE" THEN - 

MOUNT/CLUSTER/NOASSIST MOESDMAO PR00J3ISK WRKD1S 
S ! Larry or Moe. but not both, mount the dual ported disk 
S ! for the rest of the cluster 

S IF FSGETSYI ("NOOENAME") .EQS. "CURLEY" THEN GOTO SKIP_NEXT' 
S MOUNT/CLUSTER/NOASSIST S1SORA0 DOC_OISK WRKD2S 

S SKIP_NEXT: a 

S .' All nodes mount HSC disks 

S MOUNT/SYSTEM/NOASSIST DU0S0UA3 WRK3 WRKD3S 

$ MOUNT/SYSTEM/NOASSIST S255S0UA2 WRK4 WRKD4S 



3-11 



Device Naming in a VAXcluster 



Volume Shadowing 



At host request, the HSC can "shadow" data by maintaining identical data on 
a set of disk drives during on-going I/O host operations. 

Shadowing is a layered product used to ensure that critical data is not lost by 
duplicating this data on two or more compatible disk drives. 

The HSC completely manages disk shadowing internally. 

The host declares a set of disk drives as a shadow set, and then the drives are 
treated as one "virtual unit" distinct from any physical unit. 

Any disk within a shadow set: 

- Must be identical in geometry. 

- Has to be mounted through the same jJBpSittSimflfe. 

gmt mo^t &e <?aj s tenure: *eto £sro & <; 

The quorum disk cannot be shadowed. f~()lZ- — ^ 



I 



■fit* 



QVl 



or 



Sh- 



ip 
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Volume Shadowing (Cont.) 

• Install key (use release notes with key) 



$ 8SYSSUPDATE:VMSINSTAL 

Enable shadowing in SYSGEN 

S MCR SYSGEN 
SYSGEN> SET VMS 7 1 
SYSGEN> EXIT 
$ 



err c>/v 



• Mount the members of the shadow set: ^ h^ct\ l^ 1 ^ 

$ MOUNT/SYSTEM $1$0US 12: /SHADOW* ($t$0UA2.$l$DUA3) 'uSEROISK USERSDISK 



• If the disk to be shadowed is a system boot device, you must also do the 
following: 

- After installing key, copy VMB.EXE from SYSSSYSTEM to CSA1: using 

exchange: V — ^ Tc> G- €T /o£m ^Kel e Toa) bfiveji 



% EXCHANGE COPY SYSSSYSTEM :VMB. EXE CSA1: 



- Modify R3 in DEFBOO.COM to reflect a shadow set: 



' t 



OEPOSIT R3 800C0001 



Physical Drive Number 

Virtual Shadow Disk Number 

__^Informs VMB.EXE the system disk is a member of a 
shadow set 



Modify SYS$MANAGER:SYST ARTUP.COM to mount additional 
members of the shadow set. 



$ MOUNT/SYSTEM S1S0US12 : /SHA0OW«( $1$0UA1 : , S1S0UA0 ) VAXVMSRL4 
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Obtaining Status on Disks 

• The following printout is the result of typing the DCL command: 

$ SHOW DEVICE 

• The printout indicates: 

- Access path to a disk (dual- porting). 

- Number of nodes that have a disk mounted. 

- Disks mounted on another node. 

- Disks mounted on this node. 



Device 




Device 


Error 


Volume 


Free 


Trans 


Mnt 


Name 




Status 


Count 


Label 


Blocks 


Count 


Cnt 


S1SDMA1: 


(MOTHER) 


Mounted alloc 





(remote mnt) 


10342 





1 


S1S0MA2: 


(MOTHER) 


Onl ine 













S255XDJA4: 


(MUM) 


Onl ine 













S255SDUA0: 


(DUD) 


Mounted 





CLUSTERV4 


89752 


107 


2 


S255SDUA1: 


(0U0) 


Onl ine 













-S255SDUA2: 


(MUM) 


Mounted 





W0RK1 


166041 


11 


2 




Device Naming in a VAXcluster 



3-14 



Obtaining Status on Local Disks 



• The following printout is the result of typing the DCL command: 

$ SHOW DEVICE/ FULL SlSDBAl: 



• The printout indicates: 

as The device and its characteristics. 
H The device is served to cluster. 
- Where the device is mounted. 

online, mounted, file-oriented 
MSCP Server, error logging is 



Disk SlSDBAl: (STAR), device type RP06, is 
device, shareable, served to cluster via 
enabled. 



Error count 
Owner process 
Owner process ID 
Reference count 
Total blocks 
Total cylinders 
Allocation class 



00000000 
111 
340670 
815 
I 



Operations completed 23129 
Owner UIC [1.1] 
Dev Prot S : RWED . : RWED , G : RWED , W : RWED 



Default buffer size 
Sectors per track 
Tracks per cylinder 



512 
22 
19 




luster size 



Volume label "STARSS21AUG" Relative volume number 

T~^) Transaction count 
186870 Maximum files allowed 
Mount count 



Free blocks 

Extend quantity 5 

Mount status System 

Extent cache size 64 

File ID cache size 64 

Quota cache size 



Cache name 

Maximum blocks in extent cache 
Blocks currently in extent cache 
Maximum buffers in FCP cache 



93 
85167 
6 

"_$1S0BAI:XQPCACHE" 
18687 
16496 
346 



Volume status: subject to mount verfication, file high-water 
marketing, write-through caching enabled. 

is also mounted on METERO, HELOS, GALAXY , DELPHI , CYPRUS. 

JHfO rM5 vcTffri£ TO bo to/7// VfACLUST&e/ 
it /zzrees re of £u>cks ctosTeneb roQ^r/te/^ 

Fop P/lcS" ON t?tSK ■ 
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Obtaining Status on HSC Disks 



• The following printout is the result of typing the DCL command: 

S SHOW OEVICE/FULL $255$DUAO: 

• The printout indicates: 

- Type of device. 

- Host name. 



6^ 



- Host type. 

- The name of other systems that have the disk mounted. 



Disk S255SOUA0: (MUM), device type RA81, is online, mounted, 
error logging enabled. 



Error count 
Owner process 
Owner process ID 
\ Reference count 



fl Host name 



ternate host name 
ocation class 



00000000 
121 
"MUM" 
"DUO" 

255 



Operations completed 29280 
Owner UIC [1.1] 
Dev Prot S:RWED.O:RWED.G:RWED,W:RUED 
Oefault buffer size 512 
Host type, available HS50, yes 

Alternate host type, avail HS50, yes 



Volume label 



"CLUSTERV4" 



Cluster size 
Free blocks 
Extend quantity 
Mount status 
File ID cache size 
Quota cache size 
Write-thru caching enabled 



1 

289699 
5 

System 
64 



Relative volume no. 
Transaction count 
Maximum files allowed 
Mount count 
Cache name 
Extent cache size 





116 
222768 
2 

'S255SDUA0:XQPCACHE" 
64 



Volume 1s subject to mount verification, file high-water marking. 
Volume is also mounted on SUPER. 
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System Directory Structure 
Lesson Introduction 

This module discusses the directory structure on the VAXcluster system disk. Each 
VAX has its own system root. There is also a common system root shared by all 
systems booting from this disk. 

Lesson Objectives 

1. Describe the use of the common system root and specific system roots. 

2. Identify system logical names. 

3. Define the use of search lists. 

4. Find the location of diagnostics on a cluster system disk. 
Lesson Outline 

I. System Roots 

II. Logical Names 

m. Field Service Directory 



4-3 



System Directory Structure 



System Directory Structure 



Managing the Field Service Account 

Knowledge of the directory structure is important when locating diagnostics: 

• Decide how many copies of the diagnostics you want in the cluster. 

• Decide if they should be located on a shared system disk or on a single disk 
that is available to the cluster but contains only diagnostics. 

• Use of the SET LOAD command may be required to locate the diagnostics. 



4-5 



System Directory Structure 



System Directory Structure in a Cluster 

• An individual system disk has one system root (SYSO) containing all system 
files. 

• A shared system disk has: 

- Multiple system roots (SYS0,SYSl,SYS2...SYSD). 

- Each root directory contains the normal system directories (SYSEXE, 
SYSMAINT, etc.) and a directory called SYSCOMMON. 

- A new directory V4COMMON also contains normal system directories 
(SYSEXE, SYSMGR, SYSMAINT, etc). 

- SYSCOMMON is a synonym directory to V4COMMON. 

• All files in V4COMMON are the same files that are contained in the 
SYSCOMMON directory of each root. 

• Since V4COMMON and SYSCOMMON directories are synonymous, deleting 
a file from one directory causes it to be deleted from all the directories. 

• Each node, and only one node, boots from a top-level root directory (SYSn). 

• Each root is created during a VMS installation by executing a command file 
MAKEROOT.COM. 
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\JH-K 

Directory Structure of a Share cU System Disk 



000000 




SYSO 
-SYSCBI 
— SYSERR 
-SYSEXE 
-SYSHLP 
-SYSLIB 
-SYSMAINT 
— SYSMGR 
-SYSMSG 
— SYSTEST 
-SYSUPD 
-SYSCOMMON 

t 



SYS1 

-SYSCBI 
-SYSERR 
-SYSEXE 
SYSHLP 
-SYSLIB 

— SYSMAINT 
SYSMGR 

h SYSMSG 
- SYSTEST 
-SYSUPD 

— SYSCOMMON 

4 



V5 



-SYSERR 
-SYSEXE 
-SYSHLP 
-SYSLIB 
-SYSMAINT 
SYSMGR 
SYSMSG 
-SYSTEST 
-SYSUPD 



SYSCOMMON . 
SYSMAINT and 
V4C0MM0N. SYSMAINT 
are synonym 
directories 



SYSCOMMON and V4C0MM0N 
are synonym directories 



MKV84-2869 



U ^ e CLUjr^R _Coa)F(Q / COAJ 
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Logical Names and the Common System Disk Directory 
Structure 

• In an environment of clustered CPUs, logical names must support the 
different directory structure of a common system disk. 

• Logical names are created using the standard DCL ASSIGN and DEFINE 
commands. 

• Record Management Services (RMS) use logical names to implement search 
lists that look in more than one place for a file. 

• When searching for a file, the first translation is used, then the second, then 
the third, until the file is finally located. 

• The user controls the order of searching by using the DEFINE and ASSIGN 
commands to specify multiple translations of a single logical name. 

• The logical name SYS$SPECIFIC points to the node-specific root: 

"SYSSSPECIFIC" » "HSC003SOUA1:[SYS1.]" 

• The logical name SYS$COMMON points to the common directory tree: 

"SYSSCOMMON" * "HSC003$OUA1:[SYS1.SYSCOMMON.]" 
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Logical Names and the Common System Disk Directory 
Structure (Cont.) 

• Some logical names point to two directories: 

"SYSSSYSTEM" » "SYSSSYSROOT : [SYSEXE]" which translates to both: 

"SYSSSYSDEVICE : [SYSO . SYSEXE] 
"SYSSSYSDEVICE : [SYSO . SYSCOMMON . SYSEXE ] " 

• When VMS searches for a file, a search list is used to first look in the node- 
specific root and then in the common root: 

"SYSSSYSROOT" = "$ ISDUAO : [SYS3 . ]" ( LNM$SYSTEM_TA8LE ) 
» "SYSSCOMMON:" 

"SYSSCOMMON" = "$ ISDUAO :[SYS3. SYSCOMMON.]" ( LNM$SYSTEM_TABLE ) 

• To refer to a single directory, use SYS$SPECIFIC or SYS$COMMON rather 
thanSYS$SYSROOT. 

• Some logical names related to the directory structure: 

"SYSSLIBRARY" = " 255SDUA0 : [SYSO . SYSCOMMON . ] " 
"SYSSMANAGER" = "SYSSSYSROOT : [SYSMGR]" 
"SYSSNOOE" = "HARPO: : " 
"SYSSLOGIN" * "SYSSSYSTEM :SYL0GIN" 
"SYSSSYSDEVICE" = "$255$OUA0 : [SYSO . ]" 

* "SYSSCOMMON: " 
"SYSSSYSTEM" * "SYSSSYSROOT : [SYSEXE]" 
"SYSUAF" * "SYSSCOMMON: [SYSEXE ]SYSUAF. OAT" 
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Obtaining a Directory Listing 



$ OIR SYSSSYSTEM 

Olroctory SYSSSYSROOT: [SYSEXE] 



ACMSAAF.DAT; 1 
0BMMON.LOG; 162 
SETPARAMS.DAT; 3 
SYSUAF.LIS; 1 



ACMSAAU.LIS;3 
D8MMON.LOG: 161 
SORTED.0AT;2 
TEST.0UT;3 



Total of 12 files. 

Directory SYSSCOMMON: [SYSEXE] 



2020V111.EXE;1 
ACC.£XE;1 
MSACC.EXE; 4 
YEDRIVER.EXE; 1 
YEORIVER.EXE: 1 
YEDRIVER.EXE; 1 



A . MAR ; 1 
ACLEDT.EXE; 1 
ACMSADU.EXE; 4 
YFDRIVER.EXE; 1 
YFORIVER.EXE: 1 
YFDRIVER.EXE; 1 



Total of 18 files. 

Grand total of 2 directories, 30 files. 



[note 1] 

ACMSPAR. ACM;9 
JBCSYSQUE.DAT; 1 
SWAPFIIE.SYS;1 
VAXVMSSYS.OLD; 1 



[note 2] 
AA. ; t 

ACMS.MOB;4 
ACMSATLOG . EXE ; 4 
YIDRIVER.EXE.-l 
YIDRIVER.EXE; 1 
YIDRIVER.EXE; 1 



Note 1 = Files from the system specific root. 
Note 2 = Files from the common root. 
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Obtaining a Directory Listing (Cont.) 



S OIR SYSSMAINTENANCE 



Oi rectory SYSSSYSROOT: 


: [SYSMAINT] 


[note I] 


C0NFIG.COM; 1 




OUCT_CURR_ACCT . TMP ; 1 


DUCT OIAG UNSRT.TMP;2 




DUCT_0UCT.COM; 2 


SHOW. LIS; 1 






Total of 5 files. 






Oi rectory SYSSCOMHON: 


[SYSMAINT] 


[note 2] 


. ; 1 CI780.BIN: 1 




CI780_V50.BIN; I 


CI780_V70.BIN; 1 




CONSOL.SYS;30 CS800KA.SYS;2 


DIAG.C0M;9 




0IAG2.COM; 30IAGB0OT.EXE; 2 


0R750.0AT;1 




DR780.0AT; 10UB00KA. SYS; 1 


DUCT. EXE; 2 




EB0AN.EXE; 67 EBOAN.HLP;10 


EBSAA.EXE; 635 




EBUCA . COM ; 2 EBUCA . EXE ; 2 


ECKAM.HLP;5 




ECKAX . EXE ; 4 ECKAX . HLP ; 3 


ED0AA2.HLP;6 




ED0AA3.HLP;4 ED0AA4.HLP;4 


EDSAA.EXE; 239 




EEK6M.BPN; 1EEK7M.BPN: 1 


ESCCA.EXE; 1 




ESCCB.EXE; 1ESCCB. HLP: 2 


EVAAA.HLP;6 




EVAAB.EXE; 1 EVAAB. HLP ;1 


EVCKF.HLP;15 




EV0AA.EXE; I EVOAA. HLP ;1 


KA0021.PAT;1 




KA8B00.SYS;1 KA8B002.SYS; 1 


KAINIT2.SYS;1 




KKTMAQ. PAK; 1 L0A0GS.COM; 1 


MCCK01.COF_8600;l 




MC0004.CDF_8500 ; 1 MCF .BPN_860Q ; 1 


RELEASEJI0TES.DOC: 1 




RL02.COM_8600;23 RL02BUILD.CSH_8600;5 


UDKX.BPN;4 




U0KY.BPN;4 UEKM.BPN;3 


YPL0A0.COM; 1 




YOORIVER.EXE; 9 Y0L0A0.COM;! 



Total of 54 files. 



Grand total of 2 directories, 59 files. 

Note 1 = Files from the system specific root. 
Note 2 = Files from the common root. 
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VMS Build in a Cluster 



Lesson Introduction 

This module discusses installing VMS on a Cluster Common System Disk. It also 
discusses how to access and modify the S YSGEN parameters that affect the VAX as 
a node in a cluster, placement of system files, and configuration suggestions. 

Installing VMS in a cluster environment is more complicated than a single system 
installation. Manual modification of SYSGEN parameters is required after the 7 
initial installation, as well as adding additional system roots. J 

There are two different groups of parameters known as SCS and cluster. SCS 
parameters deal more with the actual Cl-to-CI communications while the cluster 
parameters define items for the SYSAPs. 

In large clusters, there may be a nned to modify the placement of certain files in 
order to make disk I/O more efficient. 

Lesson Objectives 

1. Describe how VMS is installed. 

2. Describe additional system roots. 

3. Describe the setting of particular SYSGEN parameters. 

4. List and describe the placement of Startup Command procedures. 

5. List and describe the placement of User Environment files. 

6. List and describe the placement of system files. 

7. List and define any configuration restrictions for building and maintaining a 
VAXcluster. 
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Lesson Outline 



I. 


Installing VMS 


n. 


Adding Roots 


m. 


AUTOGEN 


IV. 


Access 


v. 


Cluster 


VI. 


SCS 


vn. 


HSC Similarities 


vm. 


Command Procedures 


IX. 


Environment Files 


X. 


System Files 


XI. 


Performance Considerations 


xn. 


Disk Configuration 


xm. 


Revision Control 
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Building VMS on the First Node 



• The following steps outline how to build VMS for a shared system disk. 

• Basically, the first build is used to create all the roots for the other nodes; then 
each additional node is booted to a different root after changing each 
SCSSYSTEMID and SCSNODE parameter. 

Step 1. Install VMS from the standard distribution kit. 

Step 2. Answer "yes" to the question "Do you want to generate a cluster 
common disk?" and enter the SCSSYTEMID and SCSNODE 
parameters for the node you are on. 

Step 3. After the system shuts down, do a conversational boot (depositing 
the appropriate value in R2, R3, and R5). 

Step 4. Edit MODPARAMS.D AT to see if the appropriate values of 
SCSNODE and SCSSYSTEMID are there. 

Step 5. AUTOGEN the system. 

Step 6. After the system shuts down again, reboot. 

Step 7. Set your default at SYS$MANAGER and run MAKEROOT.COM ^ 

for each additional CPU (node) in the cluster. ^ ^1 

CLU *J[ £A - Co a; n& 

Step 8. MAKER00T.COM will prompt you for the root name (SYSn), the 
SCS node name, and the SCS system ID. 

Step 9. Shut down VMS. 
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Building VMS on Additional Nodes 

• This is a continuation of outlining a VMS build on a common system disk 
(previous page). 

• At this point, the first system boots to the SYSO directory of a common system 
disk and you have built roots for all the other nodes in your cluster on the 
same disk. 

• Also, you have edited CIBOO.CMD for the first system and copied it back onto 
the console device as DEFBOO.CMD. 

• For each additional node in the cluster, perform the following steps. 

Step 1. Perform a conversational boot (remember to change the contents of 
R5 to reflect the different root through which you are booting). 

Step 2. Edit MODPARAMS.DAT to reflect the new values of 
SCSSYSTEMID, SCSNODE parameters. 

Step 3. AUTOGEN the system. 

Step 4. Shutdown VMS. 

Step 5. Go to the next node and repeat Steps 1 through 4. 
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Using AUTOGEN 



• AUTOGEN is used to change cluster SYSGEN parameters (such as SCS node 
name and SCS system id) rather than making the changes under SYSGEN 
because: 

- You have a record of changes in MODPARAMS.DAT. 

- AUTOGEN reconfigures other parameters to reflect your changes. 

- Changes recorded in MODPARAMS are not lost during VMS updates. 

• To modify SYSGEN parameters: 

- Edit SYS$SPECIFIC:[SYSEXE]MODPARAMS.DAT. 

- Execute SYS$UPDATE:AUTOGEN.COM. 

• Sample ofMODPARAMS.DAT: 

S SET OEF SYS$SYSPECIFIC:[SYSEXE] 
$ EDIT MO0PARAMS.DAT 



Site specific AUTOGEN data file. In a VAXcluster where 
a common system disk is being used, this file should 
reside in 5Y5SSPECIFIC:[SYSEXE], not a common system 
directory. 



Add modification that you wish to make to AUTOGEN 's 
hardware configuration data, system parameter calculations 
and page, swap, and dump file sizes: 



SCSSYSTEMID«1060 
SCSNOOE s " AL F AL F " 
•EXIT 



! System 10 for the CI 
(System node name for CI 



S 9SYSJUP0ATE: AUTOGEN SAVPARAMS REBOOT 
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VAXcluster SYSGEN Parameters 

• For systems to boot properly into a VAXcluster, certain system parameters 
must be set on each cluster node using SYSGEN. 

• There are two categories of SYSGEN parameters: 

- Cluster parameters. 

- SCS parameters. 

• Cluster parameters affect the Connection Manager operation, the important 
| ones being: ^ 



V AX* CLUSTER ^ 0/»/^> 

QUORUM - TcT*u civs vcr^^^/z 
DISK__QUORUM 

QDSiVOTES — & i/cfef Fee, gvomm t>iSK 

ALLOCLASS 

VOTES 

• SCS parameters of importance are: _ e lA , i \ ^ 

SCSSYSTEMID roie/w w ^ ^ 

SCSSYSTEMIDH 

SCSNODE 

• SYSGEN can be entered on a conversational boot and VOTES changed before 
the node comes up into VMS. f(t€>t\ 5^f5B£>oT^ 

• Equivalent parameters in an HSC changed using the SETSHO utility are: 
SET ID <^ 

SET ALLOCATE "D \5 K <z — fiiiOCUA65 
'SET NAME 
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Location of Command Procedures 



/A) SVS/y>/\A)4&££ 



• In a cluster environment, the location of the following command procedures is 
important: 



SYCONFIG.COM 
V4 SYSTARTUP.COM 

SYSTARTUP G0MM0N.COM 



SYSL0GIN.COM 



Loads and configures node-specific 
drivers. 

Installs images, defines logicals, mounts 
disks, starts job controller,and sets-up 
terminal lines for specific nodes. 

Located on the system common disk; 
contains conditional code for node 
specific tasks (disk, mounts, queue 
control). 

Defines symbols that will work 
throughout the cluster. 



• Regardless of which command procedure is used during system startup, the 
rule to remember is this: 

- If a command procedure is in SYS$COMMON, it must be able to run on 
any node, 

OR 

- If a commmand procedure is node-specific, it should not be placed in the 
SYSCOMMON directory, but in the SYS$SPECIFIC directory. 
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Location of System Files 



• The following system files are important because they define the user 
environment on all nodes: 



SYSUAF.DAT 



NETUAF.DAT 



VMSMAIL.DAT 



RIGHTSLIST.DAT f^L^L 
JBCSYSQUE.DAT 



Contains login information such as 
username, password, default directory, 
quotas, and privileges. 

Contains proxy information that 
indicates which remote node/user 
combinations are allowed to bypass 
network access control checks. 

Contains mail information such as 
forwarding address and persons name. 

Contains information about what the 
user is allowed to access. 

Contains information about the various 
queues in the cluster. 



• These files are "high-usage" — constant access to them involves a lot of I/O 
activity. 

• The general rule is to take these files off the common system disk and put 
them onto a non-shared disk. 
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Location of Page and Swap Files 

• The page and swap files are used by memory management: 

SWAPFILE.SYS Provides temporary disk storage for 

processes forced out of memory by a 
memory management operation. 

PAGEFTLE.SYS Provides temporary disk storage for 

pages forced out of memory by a memory 
management operation. 

• Both swap and page files are used to save the working sets of processes that 
are not in the balance set. 

• These files are also considered "high-usage." A lot of I/O activity is centered 
around them. 

• Generally, the files PAGEFILE.SYS and SWAPFILE.SYS are moved to a disk 
other than the shared system disk. 



5-11 



VMS Build in a Cluster 



Performance Considerations 

• Disks are the primary performance bottleneck in a cluster because multiple 
nodes (CPUs) can make I/O requests to the same disk. /< v * Mixeb c^»sre£ 

• The more users who share a resource (such as a file), the more synchronization 
is needed. 

- A locking operation that requires communication between nodes takes two 
to nine times longer than a locking operation within one node. 

- If users on different nodes share files, it can take longer to lock files than if 
all users were on one node. 

• Cluster-related software overhead (Lock Manager, Connection Manager, etc) 
requires more memory as more nodes are added. 

- Any VAXcluster requires a minimum of 4 Mb of memory on each node. 

- For each node added, an addition of 1/2 Mb of memory on all nodes is 
recommended. 

• Synchronization (Lock Manager) overhead is only a fraction of total CPU time 
taken for an I/O operation — the VAXcluster usually becomes I/O bound before 
locking overhead becomes significant. 
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Disk Configurations 

• Since a VAXcIuster performance is affected most by I/O operations, the 
following guidelines for disks are useful. 

• Multiple systems can share a common system disk, but the following issues 
should be considered: 

- A single common disk repres ents a single po int of failure. jjajcES * S~ MbowtiGr i s 

-Use of multiple common disks. CH^uV \F SftAbOtftMCr 

A>CT VS£t> 

a. Example 1 

Five VAX systems (quorum is three) — since the cluster can function 
with a loss of up to two systems, configure it with three or more system 
disks, each dual-ported between two HSCs: \ 

disk 1 for two systems U f 3 c ^ / \ 

disk 2 for two systems / Pj- \) ^ \ 

disk 3 for one system f) (y^O \ 

b. Examples . . A) T ' 

Ten VAX systems (quorum is six) ~ since the cluster can function with 
a loss of up to four systems, configure it with three or more system 
disks: 

disk 1 for four systems 
disk 2 for three systems 
disk 3 for three systems 




Disk I/O performance has the following characteristics: 

- Most disks are specified for 30 to 35 1/Os per second. 

- Peak loads often triple average load. 

- Average load per spindle over 30 minutes should not exceed 10 to 15 I/Os 
per second. MONITOR- b/S/C 

- Move as much activity away from system disk as possible. 
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Disk Configurations (Cont.) 

• A dual-ported MASSBUS disk cannot be used as a system disk. 

• An RA disk can be dual-ported between an HSC and a VAX node or between 
two VAX nodes, but: 




- Automatic failover is not supported. 

- For proper failover, disk must be dismounted, port select switch from other 
port must be enabled, and then the disk remounted. 
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Revision Control 

• VAXcIusters are created from many different hardware and software 
components. 

• Revision control is important throughout the cluster — a single component 
that is not at the correct revision level may create problems for the entire 
cluster. 

• Some of the important elements include: 

- CI Port revisions (hardware and microcode). 

- CPU revisions (hardware and microcode). 

- Console floppy revisions (VMB, CI780.BIN). 

- HSC revisions (hardware and software). — ^ H0W 

- VMS version. 

- Diagnostic version. 

• Most revision control information is available in the pink fiche. 

/A) SCS — ^ V 

fcvb Reus 
ttsc 

Z>(L LOIOO 2-2.6 
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Maintenance Tools 
Lesson Introduction 

This module discusses utilities that aid in troubleshooting cluster problems. Two of 
the tools discussed, VAXsim and DECnet, require a license. 

DECnet is useful in a cluster because of its ability to add communication power 
between nodes. DECnet is not required but is strongly recommended. From a 
troubleshooting point-of-view, DECnet is only used indirectly, however its absence 
becomes extremely obvious while using other tools. 

Lesson Objectives 

1. Describe the use of VAXsim, SHOW CLUSTER, MONITOR, and 
ANALYZE/ERROR LOG. 

2. Explain how and why DECnet is used for troubleshooting. 

3. Identify problems in a cluster using the aforementioned tools. 

Lesson Outline 

I. DECnet 

H. VAXsim 

m. ANALYZE/ERROR LOG 

IV. Monitor 

V. Show Cluster 



6-3 



Maintenance Tools 



Maintenance Tools 



VAXsim (VAX System Integrity Monitor) 

• VAXsim is a layered product. 

• Provides a graphic display of hardware status within one node or across 
complete cluster. 

• Monitors errors as they are logged. 

• Performs cursory analysis rather than in-depth analysis. 

• Does not replace ANALYZE/ERROR LOG utility. 

• Provides quick indication of which option is failing, not necessarily an 
indication of what caused the problem. 
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VAXsim Data Collection 

• VAXsim Mailbox contains a current error log record (identical to what is in 
ERRLOG.SYS). 

• VAXsim Monitor is a detached process that: 

- Attaches itself to the Mailbox. 

- Reads each Mailbox entry. 

- Filters out extraneous error log information. 

- Creates and maintains its own historical database in VAXsimDAT.DAT. 

• VAXsim.EXE allows viewing of the database file. 

- Creates and maintains a display database in memory from single or 
multiple VAXsimDAT.DAT files. 

- Displays error rates and error logs. 

- Provides several display levels. 
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VAXsim Overview 



DEVICE 
DRIVERS 



VMS 

ROUTINES 



MEMORY 

ERROR_LOG 

BUFFERS 



® 



ERRFMT 
PROCESS 



VAXsim 


MONITOR 








VAXsimDAT.DAT 



REPORT GENERATOR ;r 

VAX SYSTEM 




VIDEO DISPLAY 
REPORT 



MKV85-O090 
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Analyze Utility 

• ANALYZE/ERROR LOG formats the error log entries (from ERRLOG.SYS 

file) into a readable format. 

• Command options are used to narrow down the error log output to: 

- A specific device. 

- A specific time. 

- A particular form. 

• To obtain output related only to a specific device, use the /INCLUDE option: 

S ANAL/ERR/INCLUDE S 0UA1 : 

• To obtain output of only a particular type of error, use the /INCLUDE and 
/EXCLUDE options: 

$ ANAL/ERR/ INCLUDE *DUA I: /EXCLUDE »VOLUME_CHANGES 

• To obtain output relating to a particular time use the /SINCE and /BEFORE 
options: 

$ ANAL/ERR/INCLUOE»PAA0/SINCE=14-JAN-t988/BEFORE»14-JAN-1988 

• Use the /SUMMARY = HISTORGRAM option for a quick view of the number 
of errors and the time of occurrence: 

S ANAL/ERR/ INCLUDE *PAAO/SUM»HIST/NOFULL 
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Monitor Cluster Utility 

• Gathers data for up to sixteen nodes in a cluster. 

• Data items examined include: J- 

- Percent of CPU in use. j> [V ,fQ 

- Percent of memory in use. / v <n w . 

- I/O operation rate. \J Jfr 

- Total ENQ/DEQ rate. 

• Especially useful for monitoring and recording total disk activity. 

• Format of the output can be "tabular" or "bar-graph" 

• Uses DECnet to establish a monitor server process on each node from which it 
gathers data. 
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Show Cluster Utility 

• The SHOW CLUSTER command provides a view of the VAXcluster from a 
single node. 

• The SHOW CLUSTER command provides a view of the VAXcluster and then 
returns user to DCL prompt. 

• The SHOW CLUSTER/CONTINUOUS command displays data continuously 
and updates the display at specific intervals. 

• The /CONTINUOUS qualifier allows the user to enter a utility command that 
changes the contents of the display, allowing the user access to over 100 fields 



• The SHOW CLUSTER report consists of three windows from which data is 
collected for all fields: 



of data. 



SCS window 



Contains data collected from the System 
Communications Services database (SCS). 



CLUSTER window 



Contains data collected from the Connection 
Manager database. 



LOCAL PORTS window 



Contains data collected from the CI Port 
database. 
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DECnet in a VAXcluster 

• DECnet should be installed and running on every node in a VAXcluster. 

• No cluster component requires DECnet for communication, but DECnet 
provides many functions that can complement cluster operation and 
management: 

- Allows access to disks that are not available cluster- wide. 

- Allows logins on any cluster node from any terminal using the SET HOST 
command. 

- Allows distributed applications that require DECnet to work (VAXsim, 
MONITOR). 

- Allows VAXcluster nodes to be part of a larger network. 

• The DECnet class driver can operate over the CI Bus, but normally this is not 
done. 

- The Ethernet path yields faster throughput and less overhead. 

- DUP must use CI since Ethernet does not attach to the HSC. 

• DECnet account in UAF must match the DECnet account of NCP. 
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